今日主題

今天的主題是Scenario testing，所謂的情節需要角色以及故事，通常是經過觀察使用者與產品之間的互動關係，從使用者角度出發來了解產品是如何被使用、又滿足了那些需求。由於是模擬真實的使用情況，所以Scenario testing設計出來的測試流程相當貼近實際狀況，主要的困難點在觀察階段的收集與分析，再來就是功能的拆分了。

對應到今天的挑戰內容，我們將會實際設計多個請求，設定其執行順序來完整描述某個使用情境，過程將會用到很多前面章節討論的內容，包含API specification、Collection runner等等，算是一個總複習的篇章。那麼在開始之前，別忘了先把 Day 27: Scenario testing 複製到自己的工作區。

回到自己的工作區，打開今天的資料夾Scenario testing，從右方的文件區可以了解到，今天會使用多個銀行的API來體驗一個帳號的創建、登入、登出的流程，操作步驟如下:

• 導入API:
  利用前面章節講過的方法，將 https://raw.githubusercontent.com/kmmanoj96/vulnerable-apis/main/openAPISpecBank.yaml 內容載入到Postman並自動生成相關API

  

  記得啟用Copy collections to workspace，來將產生的API複製到工作區

  

• 新增子資料夾
  在今天的資料夾Scenario testing下面新增兩個資料夾

  • Setup
  • New user workflow

• 新增變數
  在今天的Collection Day 27: Scenario testing 新增一個環境變數baseUrl，值為http://security.postman-breakable.com

  變數內容來自剛剛在工作區剛剛產生的Good Bank API這個collection裡的變數

• 新增請求
  從剛剛產生的Good Bank API collection裡找到 POST Create User 這個請求，複製到今天的資料夾Setup之下，修改其body下的參數username以及password，嘗試發送來建立一個帳號，如果建立成功則會從回應裡取得user_id的值，需要在今天Day 27的collection裡新增變數user_id，填入剛剛創建得到的值。所以目前在Setup資料夾下我們擁有一個可以建立帳號的API，也有一個user_id環境變數了。

• 新增情境
  在這個步驟我們要建立起幾個有先後順序的請求，來描述使用者的使用情境，都是先從Good Bank AP找API，然後複製到今天建立的資料New user workflow下，詳細的步驟如下

  • 1. POST User Login
    • 從 user/User Login 複製而來
    • 修改body，選擇raw調整成JSON格式，填入前面建立帳號所用的帳號密碼

      {
         "username": "testuser123",
         "password": "testpass123"
      }
      

    • 嘗試發送
      這是用來登入用的API，所以成功的話會回傳 user_id 以及 session_token
    • 新增測試
      主要測試API本身成功之外，還需要把後面API會用到的資料寫進環境變數user_id、token

      pm.test("Status code is 200", function () {
          pm.response.to.have.status(200);
      
          let response = pm.response.json().response
          let user_id = response.user_id
          let token = response.session_token
          //console.log(user_id, token);
          pm.collectionVariables.set('user_id', user_id)
          pm.collectionVariables.set('token', token)
      });
      

    • 設定api key
      到資料夾New user workflow的Authorization進行設定

      

  • 2. GET Get User Information : 由於 Bank API 沒有提供範例所以需要自己改
    • 從 user/Update User Information 複製而來
    • 命名為 Get User Information
    • 將方法改為 GET
    • 將Body選擇 none
    • Authorization調整成繼承
    • 新增測試，確認狀態碼是否為200
    • 嘗試發送確認通過測試，成功也能從回應看到該帳號的資訊
  • 3. GET Account summary

    • 從 account/Account summary 複製而來

    • 調整參數來指定user_id

      

    • 新增測試，確認狀態碼是否為200

    • 嘗試發送確認通過測試

  • 4. GET User Logout
    • 從 user/Logout 複製而來
    • 新增測試，確認狀態碼是否為200
    • 嘗試發送確認通過測試
  • 5. GET Account summary
    • 同第三個請求，只是順序在使用者登出之後
    • 新增測試，因為已經登出了，所以這裡要確認狀態碼是否為403

      pm.test("Status code is 403", function () {
          pm.response.to.have.status(403);
      });
      

• 批次執行
  新增完請求後，今天的Collection會長得像這樣

  

  然後在資料夾New use workflow旁邊三個小點的選項找到Run folder來批次執行下面所有的請求，將會依序執行資料夾內所有請求，結果如下

  

• submit
  到這邊就可以進行submit了，如果有測試錯誤的話，可以檢查每個請求是不是都有新增測試，另外就是Authorization都調整成繼承模式，來統一使用設定在資料夾New use workflow內的api key。

今日回顧

今天我們實際新增了好幾個請求來模擬使用者實際的一個使用情境，除了新增使用者的API之外，其他的請求有著順序的相依性，大多數的API都需要先進行登入才能繼續，而另外登出後的行為也相當重要，因此今天的體驗裡我們也透過重複定義的請求，去看它在登入前以及登入後是否都如同我們預期的工作一樣。

以往的Tests只能確保單一API是否正常工作，而情節測試更貼近於使用者的真實情況，畢竟有些功能必須透過多個API互相搭配才能夠完成，而Postman提供的機制也能很好的處理這樣的需求。

那麼今天就到這裡，我們明天見~